reordered by yarn add

new installed packages:

"@nrwl/devkit": "12.1.0",
    "@nrwl/jest": "12.1.0",
    "@nrwl/node": "12.1.0",
   tslib": "2.2.0 --> added to root (single version policy)

propagated packages from scripts/ to single version policy as they had chalk as a dep which was causing issues

"just-scripts": "1.3.1",
"webpack-dev-middleware": "4.2.0",    
"webpack-hot-middleware": "2.25.0",

bumped chalk to 4.1.0
-> after I added additional @nrwl/* packages (they have chalk 4.1 as dependency),
build started to fail
-> because react-conformance still depends on old chalk 2 ( which did lot of mistakes regarding exposing APIs for js and ts consumers), so scripts/exec was loading chalk 4.1 but react-conformance was supposed to consume 2.x but because you cannot consume 2 versions of the same package without hacks (aliasing), react-conformance got v4 which has different API and thus failed build

propagated tslib to single version policy for devtooling

I turned off checks for devDeps. This tool wont work with what we agreed upon
-> single version policy === exact versions
-> published package deps === caret versions

I'm not sure this is a good idea until we have complete single version policy for dev deps (and tooling to enforce it). Instead I wonder if you could add a versionGroups entry something like this:

{
  "packages": ["fluent-ui-react-repo"],
  "dependencies": ["tslib", ...]
}

(If there's some other syncpack setting we need to support this scenario longer-term, the syncpack author has been pretty responsive to suggestions.)

this works:

   {
        "packages": [
          "fluent-ui-react-repo"
        ],
        "dependencies": [
          "tslib",
          "webpack-bundle-analyzer",
          "chalk"
        ]
      },

although I don't think this is what we want, as it will allow further misalignments between versions.

What would be probably needed as a feature for syncpack is the ability to specify devDependencies similarly to how dependencies work.

chalk v4 api

run nx workspace lint checks on ci to prevent getting out of sync whilst doing changes by hand

environment scoped TS config - this is the future for every convergence package (will mitigate issues like this -> #17101)

this is only one special case for nx, as it compiles down TS source of workspace generators - it uses this file in particular

I'm still a bit confused by intention of both tsconfig.tools.json and tsconfig.lib.json, why are both necessary ?

sorry about that.

• tsconfig.tools.json is used to run tsc when executing nx workspace-generator <generator-name> runner
• tsconfig.lib.json is standard part of every package ( 100% converged to nx ), which is used for production builds (transpile/rollup) and as source of truth for type checking implementation files.
  • I added it to /tools to keep the default boilerplate consistent

this is a showcase how task managed will look like in the future with full nx adoption. for now, it's leveraged only for tools/

Will we be duplicating this kind of json config for all packages listed in the workspace.json in the future ?

Will we be duplicating this kind of json config for all packages listed in the workspace.json in the future ?

we might, yes -> meaning no more package.json#scripts. It gives us various benefits over primitive npm scripts, integration with vscode plugin etc.

spoiler alert -> nx 13 will add new features that this huge workspace json will be dissected into smaller ones per package

I guess anything in tools will not declare dependencies in package.json and just consume from the root right ?

yes, single version policy from the start.

• also because this will never be published
  • there is no need to provide deps
  • if we might change our minds, nx generates package.json with deps automatically (based on AST/dependency graph)

is this generated from the schema.json or maintained manually ?

generated. we can add that tooling later.

this default value is declared in schema.json, does this mean nx does not handle default values declared in the schema ?

this default value is declared in schema.json, does this mean nx does not handle default values declared in the schema ?

• it does, typescript doesn't - the ultimate problem of default vs optional values.

JSX has special hack for that in TS compiler (via *.defaultProps), outside of that we are out of luck. I mean it can be hacked via additional TS type transforms which adds additional churn, from my experience this is the most concise way. If you have other proposal how to handle this lemme know!

The "churn" I mentioned:

import { WorkspaceGeneratorGeneratorSchema } from './schema';

// while this looks "ok" for 1 property, for more it might become hard to read ?  (YMMV)

interface SchemaWithAccommodatedDefaults extends Required<Pick<WorkspaceGeneratorGeneratorSchema,'skipFormat'>>,WorkspaceGeneratorGeneratorSchema {}

export default async function(host: Tree, schema: SchemaWithAccommodatedDefaults) {
 // ....
}

I'm not sure this is a good idea until we have complete single version policy for dev deps (and tooling to enforce it). Instead I wonder if you could add a versionGroups entry something like this:

{
  "packages": ["fluent-ui-react-repo"],
  "dependencies": ["tslib", ...]
}

(If there's some other syncpack setting we need to support this scenario longer-term, the syncpack author has been pretty responsive to suggestions.)

What's the reasoning for turning this off? Was the config not properly allowing deps from the root config (there's a setting for that), or some other issue?

I know there is the setting, but it doesn't work unfortunately

This works for me locally:

"import/no-extraneous-dependencies": ["error", { "packageDir": [".", ".."] }]

Actually never mind, that works in the UI but not in the tool. To make it work while running yarn lint it has to be "packageDir": ["."]--I guess nx run runs stuff with cwd as the repo root?

I don't think we ever made a decision about whether to put the output in a single dist folder at the root. Unless it's necessary for nx to have it at the root for some reason, could it stay inside the tools folder for now?

Unless it's necessary for nx to have it at the root for some reason, could it stay inside the tools folder for now

• right, this is default nx boilerplate. In general every build output is stored within root dist/ -> /dist/<package-name>/.....
  • a) this is required for TS when path aliases are used ( currently we "hack it" by removing aliases during lage builds)
  • b) I mentioned reasoning in this RFC
• in reality within /tools, this config file is solely for proper type checking per environment ( in this case, lib -> implementation code )